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Beschreibung 

[0001] Die Erfindung bezieht sich auf ein System zur Verifikation von Software-Anwendungsmodellen in Ketten von 
Software-Entwurfswerkzeugen. 

5 [0002] Bei der Erstellung von IT-Systemen kommen vermehrt Werkzeuge und wiederverwendbare Softwarebaustei- 
ne - auch Komponenten genannt - zum Einsatz, welche die Entwickler in ihrer Arbeit unterstutzen. Dabei gibt es eine 
nahezu unuberschaubare Menge an Werkzeug- und Komponententypen. Beispiele sind einfache Texteditoren zum 
Bearbeiten von Quellcode, Werkzeuge zur Erfassung von Anforderungen an ein Software-System, Design-Werkzeuge, 
Ubersetzer, Generatoren, Transaktionsmanagement-Systeme, Datenbanken oder ganze Ablaufumgebungen fur An- 

10 wendungen, sog. Application Server. Je nach Ausgestaltung eines Software-Entwicklungsprozesses werden viele sol- 
cher Werkzeuge zusammengefaBt und miteinander integriert, wobei sich zumeist definiert durch den ProzeB eine klare 
Reihenfolge erkennen laBt, in der die Werkzeuge in der Entwicklung zum Einsatz kommen. In solchen Fallen kann 
von einer Werkzeugkette gesprochen werden. Am Ende eines vollstandigen und korrekten Durchlaufs durch eine sol- 
che Kette steht ublicherweise ein lauffahiges Software-System. 

15 [0003] Es gibt im Bereich des computergestutzten Softwareentwurfs und der-entwicklung, auch CASE - Compu- 
terAided Software Engineering genannt, eine Vielzahl von machtigen Werkzeugen, teils als kommerzielle Produkte 
kauflich, teils als kostenlose Software beispielsweise aus dem Internet beziehbar. Interessant ist hier vor allem die 
Betrachtung bereits verfugbarer Werkzeug/ceften, die als solche ausgepragt sind. 

[0004] Hier sind zum einen die "klassischen" integrierten Entwicklungsumgebungen, sog. IDE - integrated Develop- 

20 ment Environment zu nennen, die sich in der Vergangenheit zumeist darauf beschrankten, eine nahtlose Integration 
zwischen Editor, Konstruktionshilfen fur graphische Benutzungsschnittstellen, Ubersetzer, Debugger und oftmals ex- 
ternen Werkezeugen wie z.B. Versionierungs- und Konfigurationsverwaltungswerkzeugen herzustellen. Nennenswerte 
Produkte in diesem Bereich sind SNiFF+ von der Firma TakeFive, jetzt WindRiver, JBuilder von der Firma Borland / 
Inprise, Symantec Cafe von der Firma Symantec Oder Visual C++/J++ von der Firma Microsoft. 

25 [0005] Zum anderen gibt es im Bereich der engeren Fassung des Begriffes CASE einige Werkzeugketten, die den 
Anwender von den fruhen Phasen des Entwurfs, also z.B. der Analyse und der Erfassung der Anforderungen begleiten 
bis hin zur Erzeugung des lauffahigen Software-Systems. Beispiele hierfur sind die Werkzeuge der Firma Rational, 
die Produkte der Firma Together oder das Produkt >4rcSfy/er von der Firma Interactive Objects Software GmbH. 
[0006] Auch im akademischen Bereich gab es Forschung zum Thema der Integration von Werkzeugen zum Soft- 

30 wareentwurf. Hier ist besonders zu erwahnen das Projekt STONE (siehe Eduardo Casais, Claus Lewerentz, STONE 
project monograph: Issues in Tool Integration, Forschingszentrum Informatik, Karlsruhe, ISSN 0944-3037), das zu 
Teilen am Forschungszentrum Informatik an der Universitat Karlsruhe TU durchgefuhrt wurde. 
[0007] Beim Durchlaufen einer Werkzeugkette gibt es zahlreiche potentielle Fehlerquellen. Daher bieten die meisten 
Werkzeuge eine mehr oder weniger gut ausgepragte Unterstutzung in der Auffindung und Behebung von Fehlern an. 

35 Ein eingangiges Beispiel fur die Fehlererkennung in solchen Werkzeugketten sind die syntaxbewuBten Quellcodeedi- 
toren. Dabei findet in der Regel eine farbliche Hervorhebung syntaktischer Elemente im Quellcode durch den Editor 
statt, so daB der Entwickler moglichst rasch und leicht Konstrukte im Code identif izieren kann, die von nachgeschalteten 
Werkzeugen, z.B. dem Ubersetzer, fur unzulassig erkannt wurden. So erspart dieses Vorgehen in manchen Fallen 
einen unnotigen Ubersetzerdurchlauf, der nur die bereits fruher erkennbaren Fehler aufgedeckt hatte, urn nach an- 

40 schlieBender Uberarbeitung der Eingaben wiederholt ausgefuhrt zu werden. 

[0008] Dabei wird jedoch explizit im vorgeschalteten Werkzeug, im Beispiel dem Editor, Wissen uber Randbedin- 
gungen eines nachgeschalteten Werkzeugs integriert. So enthalt beispielsweise ein im Werkzeug JBuilder von der 
Firma Borland/ Inprise integrierter Editor zwar die Regeln fur die Syntax der Programmiersprache Java, nicht jedoch 
die der Sprache Fortran. Wurden also mit diesem Editor Fortran-Quellen bearbeitet, so konnte der Editor keine Unter- 

45 stutzung im Syntax-Bereich mehr bieten. Wichtig zu erkennen ist also hier die Integration des Wissens uber nachge- 
schaltete Werkzeuge als fester Bestandteil eines vorgeschalteten Werkzeugs beim Stand derTechnik. 
[0009] Fur Werkzeuge, welche die hoherwertige Semantik eines Software-Systems zu modellieren gestatten, sind 
solche antizipativen Fehlererkennungshilfen nicht verfugbar. Beispiele fur solche Werkzeugtypen sind Analysewerk- 
zeuge etwa zur Erfassung von Klassenkarten - die sog. CRC-Technik - Class, Responsibility, Collaboration - oder zur 

50 Beschreibung von Designs in Modellierungssprachen wie der UML - Unified Modeling Language (siehe auch James 
Rumbaugh, Ivar Jacobson, Grady Booch, The Unified Modeling Language Reference Manual, Addison Wesley Long- 
man, Reading MA, 1999). 

[001 0] Erwahnenswert ist auch der Bereich der Emulation oder Simulation. Hier ahmen Softwaresysteme das Ver- 
halten anderer Systeme nach. Zum Beispiel gibt es Software-Emulatoren fur Mikroprozessoren. Der Nachteil emula- 
55 tiver Systeme ist, daB sie im Gegensatz zu einem Modell der Fahigkeiten eines Werkzeugs oder einer Komponente 
in der Regel keinerlei Verkurzungsaspekt gemaB der Modelltheorie aufweisen, also die Durchfuhrung bestimmter Uber- 
prufungen in keiner Weise vereinfachen. Anders gesagt ergibt sich durch Emulation in dem hier betrachteten Zusam- 
menhang kein Vorteil gegenuber der tatsachlichen Umschaltung in das betreffende Werkzeug, da nur das ganze Werk- 
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zeug selbst "dupliziert" wird, nicht jedoch seine fur die Fehleranalyse entscheidenden Regeln und Bedingungen. 
[0011] Ein weiterer Bereich, in dem Eigenschaften von Systemen, Werkzeugen und Komponenten bereits fruh in 
einem EntwurfsprozeB eine Rolle spielen, ist die Architektur, hier besonders der Bereich Hochbau. Dabei gehen die 
Eigenschaften etwa von Baumaterialien bereits in die Planungsphase ein. So beeinfluBt beispielsweise die Tragfahig- 
5 keit von Stahlbeton den Entwurf der Decken in einem Hochhaus. Im Architekturbereich ist jedoch eine Formalisierung 
dieses Prozesses nicht gegeben. Das Problem wird hier durch vermehrte Kommunikation zwischen den beteiligten 
Personen gelost. Beispielsweise werden in den PlanungsprozeB neben dem Architekten auch Bauingenieure Oder 
Statiker mit einbezogen, die dann den Architekten beim Entwurf unterstutzen und von ihm geplante Konstruktionen 
auf Machbarkeit uberprufen. 

10 [0012] Es ist eine zentrale Erkenntnis, nicht nur im Bereich der Informationstechnologie, daB die fruhzeitige Erken- 
nung und Behebung von Fehlern erheblich zur wirtschaftlichen Durchfuhrung von Entwicklungsprojekten beitragt. Mit 
wenigen Ausnahmen, z.B. vorgenannte Quellcode-Editoren, existiert jedoch eine antizipative Fehlererkennung entlang 
einer Werkzeugkette im Bereich des Softwareentwurfs bisher nicht. Dadurch werden viele Fehler erst spat in der Kette 
entdeckt, und es vergrdBert sich somit die Anzahl an Durchlaufen durch den Entwicklungszyklus zur Behebung dieser 

^5 Fehler. Das ist aufwendig und kostet viel Zeit und Geld. 

[0013] Ein ursachliches Problem ist dabei die Sicht eines jeden Werkzeugs entlang einer Kette, die eingeschrankt 
ist auf die von ihm bearbeiteten Aspekte des Gesamtsystems. Eine ganzheitliche Sicht fehlt. 
[0014] Auch sind die wenigen vorhandenen Mittel, wie etwa Syntaxhervorhebung in Quellcodeeditoren, nur mit ge- 
ringem semantischen Wissen uber die tatsachlich zu prufenden Bedingungen ausgestattet. Zum Beispiel konnen die 

20 meisten Quellcodeeditoren zwar Schlusselworter der Zielsprache erkennen und entsprechend hervorheben; die Uber- 
prufung, ob die Verwendung des Schlusselwortes an diese Stelle zulassig ist, unterbleibt jedoch in aller Regel. 
[001 5] Etwas weiter geht hier der Ansatz, den Werkzeuge im Bereich der Softwareentwicklung mit der Programmier- 
sprache Smalltalk vertolgen. Dort sind der Quellcodeeditor und die syntaktische und semantische Analyse des Codes 
eng miteinander verwoben. Man konnte soweit gehen und von einem integrierten Werkzeug sprechen. Dadurch wird 

25 zwar auf der einen Seite eine rasche und einfache Prufung des Quelltextes moglich, auf der anderen Seite ist die 
Anpassung der zu prufenden Regeln und damit die Verwendung des Editors mit einer anderen Programmiersprache 
nicht mehr moglich. 

[001 6] Ein weiterer entscheidender Punkt ist, daB durch die Vielzahl verfugbarer Werkzeuge und Komponenten die 
daraus ableitbare Anzahl von verschiedenen moglichen und sinnvollen Werkzeug kette n sehr groB ist. So konnte bei- 
30 spielsweise ein Design-Werkzeug prinzipiell zwar erkennen, daB ein bestimmtes Design nicht auf das gewahlte Da- 
tenbankprodukt abbildbar ist, aber dazu fehlt es bis jetzt den Designwerkzeugen an offenen Schnittstellen, uber die 
eine Beschreibung der Regeln nachfolgender Werkzeuge und Komponenten so erfolgen kann, daB sie vom Desi- 
gnwerkzeug uberpruft werden konnten. 

[0017] Daraus ergeben sich nachfolgend Probleme, sol! einmal ein Werkzeug oder eine Komponente in der Kette 
35 ausgetauscht werden. Im schlimmsten Fall treten bestimmte Fehler erst in einem ausgelieferten System auf, weil sie 
zuvor unentdeckt blieben. Wahrend man heute diesen Problemen durch massiven Testaufwand im Vorfeld einer Aus- 
lieferung begegnet, konnen durch verbesserte Werkzeugunterstutzung bei der Fruherkennung von Fehlern diese Auf- 
wande erheblich reduziert werden. 

[0018] Der Erfindung liegt die Aufgabe zugrunde, ein System anzugeben, das es ermoglicht, entlang einer Werk- 
40 zeugkette fruhzeitig im EntwurfsprozeB Fehler in dem im Entwurf befindlichen Software-Anwendungsmodell zu erken- 
nen, und zwar ubergreifend uber die Aspekte aller beteiligten Werkzeuge und Komponenten entlang der Kette. 
[0019] Diese Aufgabe wird gelost durch ein System zur Verification von Software-Anwendungsmodellen in Ketten 
von Software-Entwurfswerkzeugen mit den im Anspruch 1 angegebenen Merkmalen. Vorteilhafte Ausgestaltungen 
sind in weiteren Anspruchen angegeben und der nachstehenden Beschreibung von Ausfuhrungsbeispielen zu ent- 
45 nehmen. 

[0020] Bei der Erfindung handelt es sich urn ein System, das es ermoglicht, Bedingungen und Regeln fur ein Soft- 
ware-Anwendungsmodell so zu formulieren, daB sie anschlieBend auf ein bestehendes Software-Anwendungsmodell 
angewendet und das Modell somit auf Vertraglichkeit mit diesen Bedingungen und Regeln uberpruft werden kann. Die 
Regeln/Bedingungen konnen dabei zu Gruppen zusammengefaBt werden, die beispielsweise jeweils aus der Sicht 
50 eines einzelnen Werkzeugs oder einer einzelnen Komponente formuliert sind. Die Anwendung und Uberprufung der 
Regeln kann jedoch unabhangig von einem bestimmten Werkzeug zu beliebiger Zeit an beliebiger Stelle in der Werk- 
zeugkette stattfinden. Die Gesamtmenge der jeweils gultigen Regeln/Bedingungen ergibt sich dann aus der Kombi- 
nation derjenigen Regelgruppen zu den Werkzeugen und Komponenten, die in der verwendeten Werkzeugkette ar- 
rangiert wurden. 

55 [0021] Die Beschreibung der Regeln erfolgt unter Verwendung der Schnittstelle des Modells, welche durch ein Me- 
tamodell definiert wird. Neben dem Modell kann eine Regel auf eine vom Software-Anwendungsmodell unabhangige 
Parametermenge zugreifen, welche beispielsweise die Fahigkeiten einer eingesetzten Softwarekomponente be- 
schreibt und somit Anforderungen an das Model! beschreibt und / oder parametriert. 
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[0022] Das System laBt sich in folgende Teile untergliedern, die im AnschluB detailliert erlautert werden: 
[0023] Grundlage ist das Metamodell, welches die Struktur von und Schnittstellen zu Modellen von Software-Syste- 
men beschreibt und auf dem alle Werkzeuge in einer Kette aufbauen. Die Regeln und die diese uberprufenden Algo- 
rithmen sind in einem sogenannten Verifier Framework zusammengefugt. Regeln konnen flexibel paramefr/erf werden, 
5 wobei ein spezielles Verfahren die Wiederverwendung von Parametergruppen erlaubt. Zuletzt wird noch die Integration 
der Regelprufung in eine We rkzeug kette beschrieben. 

Metamodell 

10 [0024] Als Grundlage des hier verwendeten Metamodells fur die Beschreibung von Modellen von Software-System en 
wird hier der UML-Standard eingesetzt. Damit sind die Basiselemente eines objektorientierten Software-Systems be- 
schreibbar, beispielsweise Classifier, Namespace, Operation, Parameter o6er Generalization. Die Erfindung ist jedoch 
auch auf Erweiterungen eines solchen Standard-Metamodells, z.B. UML profiles, oder auf beliebige andere Meta- 
modelle anwendbar, z.B. wenn das Modell zusatzlich Zusammenhange zwischen Teilen einer Komponente zu be- 

15 schreiben erlaubt, wie dies der CCM- CORBA Components Standard vorsieht oder wenn Quellcodeelemente als Teile 
des Modells beschrieben werden. 

[0025] Es muB eine definierte Schnittstelle geben, uber die auf Instanzen des Metamodells, also auf Modelle von 
Software-System en, zumindest lesend zugegriffen werden kann. Dabei mussen uber diese Schnittstelle die Eigen- 
schaften der im Modell beschriebenen Elemente und deren Beziehungen untereinander abfragbar sein. 

20 

Verifier Framework, Anwendung von Verifiern auf Modettelemente 

[0026] Wie bereits oben erwahnt werden Regeln zu Gruppen zusammengefaBt. Diese Gruppen werden mit dem 
Begriff Uertf/erbezeichnet. Das Verifier Framework regelt nun das Zusammenspiel der einzelnen Verifiers und deren 
25 Ausfuhrung / Uberprufung gegen ein bestehendes Modell. 

[0027] Grundidee des Frameworks ist es, eine Menge von Verifiern auf eine Menge von Modellelementen anzuwen- 
den und dabei alle gefundenen Regelverletzungen aufzuzeichnen. Zu diesem Zweck muB das Framework folgende 
Fahigkeiten bieten: 

30 o Zusammenstellung einer Menge anzuwendender Verifier 

• Festlegung der Menge von Modellelementen, auf die die Menge von Verifiern anzuwenden ist 

• Ausfuhrung der Verifier auf alien zuvor festgelegten Modellelementen bei gleichzeitiger Protokollierung aller fest- 
35 gestellten Regelverletzungen 

• menschen- und maschinenlesbare Presentation der gefundenen Verletzungen sowie konstruktive Fehlerbehe- 
bungshilfen 

40 [0028] Die Zusammenstellung der anzuwendenden Verifier erfolgt durch eine eigens dafur vorgesehene Komponen- 
te, den Verifier Manager. Uber diese konnen dem Framework Verifier bekanntgegeben werden. Einzelne Verifier kon- 
nen damit dynamisch zu einem Uberprufungslauf hinzugenommen oder abgeschaltet werden. Dies kann dabei ent- 
weder programmatisch durch eine Anwendung geschehen, die sich der Funktionalitat des Verifier Frameworks bedient, 
oder durch eine eigene interaktive Benutzungsschnittstelle des Frameworks. 

45 [0029] Die Auswahl der Modellelemente, auf die die festgelegten Verifier anzuwenden sind, erfolgt durch explizite 
Auflistung. Zusatzlich kann fur solche Modellelemente, die weitere Modellelemente enthalten, z.B. ein Package, fest- 
gelegt werden, ob die Regeln bei einem Durchlauf auch transitiv auf die enthaltenen Elemente angewendet werden 
sollen. Urn also beispielsweise das gesamte Modell auf RegelverstoBe zu uberprufen, mussen lediglich die Package- 
Modellelemente, die sich nicht in weiteren Package- Strukturen geschachtelt befinden, ausgewahlt werden, und die 

so Regeln mussen transitiv auf alle enthaltenen Modellelemente angewendet werden. Dadurch wird dann das gesamte 
Modell erfaBt. 

[0030] Bei der Ausfuhrung der Verifier gegen die Modellelemente nutzt das Framework die Tatsache aus, daB jeder 
Verifier eine - jeweils die gleiche - Schnittstelle zur Ubergabe eines Modellelements zur Uberprufung durch diesen 
Verifier unterstutzen muB. Somit kann das Framework homogen und durch Ausnutzung der objektorientierten Technik 
55 der Polymorphie '\e6err\ registrierten und ausgewahlten Verifier jedes zur Uberprufung anstehende Modellelement uber 
diese Schnittstelle zur Prufung vorlegen. Das Ergebnis einer jeden solchen Prufung ist eine Liste gefundener Regel- 
verletzungen, die jeweils genugend Information enthalten mussen, urn daraus eine informative Meldung fur den An- 
wender abzuleiten, so daB fur diesen der gefundene VerstoB eindeutig identifizierbar und somit behebbar wird. Entlang 
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tier Ausfuhrung aller selektierten Verifier auf alle festgelegten Modellelemente werden diese Regelverletzungslisten 
gesammelt und zusammengefugt, so daB am Ende eine einzige Gesamtliste entsteht, die dem Anwender prasentiert 
werden kann. 

[0031 ] Es ist hierbei wichtig zu erwahnen, daB eine Regel auch spezifisch fur bestimmte Arten von Modellelementen 
5 sein kann. Es ist die Aufgabe des Verifiers, zu bestimmen, welche seiner enthaltenen Regeln er tatsachlich auf ein an 
ihn zur Oberprufung ubergebenes Modellelement anwendet 

[0032] Bei der Presentation der Regelverletzungen werden folgende Aspekte einer Verletzung berucksichtigt: Die 
Schwere der Verletzung, also z.B. "Warnung" oder "Fehler", Auswirkungen des Fehlers Oder der Warnung, z.B. Per- 
formance-EinbuBen, ein informativer Text im Sinne einer Fehlermeldung, konstruktive Hinweise zur Behebung des 
10 Fehlers und eine Liste beteiligter Modellelemente, aus der fur den Anwender ablesbar ist, an welcher Stelle im Modell 
genau die Verletzung vorliegt und mitunter wie sie zustandekommt. Wenn das Werkzeug, in das die Prufung integriert 
ist, die Kenntlichmachung von Modellelementen unterstutzt, kann diese Eigenschaft ausgenutzt werden, urn die be- 
teilgten Modellelemente hervorzuheben. Diese Attribute der gefundenen Regelverletzungen lassen sich elegant in 
einer graphischen Presentation zusammenfugen. 

15 

Flexible Parametrierung von Verifiem und die Uberladungssemantik bei der Beschreibung dieser Regeln in Sequenzen 
von XML-Dateien 

[0033] Das bisher Gesagte laBt weitestgehend offen, wie die Regeln und die durch sie ausgedruckten Anspruche 
20 an das Modell formuliert werden. Soweit wurde nur gefordert, daB das Metamodell die Schnittstelle vorgibt, uber die 
die Regeln auf das zu prufende Modell des Software-Systems zugreifen konnen. Es gibt jedoch Randbedingungen, 
die weitergehende Uberlegungen rechtfertigen: 

[0034] Oftmals erfullen Komponenten und Werkzeuge entlang einer Werkzeug kette bestimmte Standardaufgaben, 
fur deren Erledigung nicht ausschlieBlich das spezielle, ausgewahlte Werkzeug in Frage kommt. Andere Werkzeuge 
25 und Komponenten mogen weitestgehend die gleichen Anforderungen erfullen, moglicherweise jedoch jeweils mit ge- 
wissen Abweichungen und Unterschieden. Daraus lassen sich entsprechend unterschiedliche Verifier ableiten, die 
zum einen Standardregeln, zum anderen spezielle Regeln fur die Abweichungen des gewahlten Werkzeugs bzw. der 
gewahlten Komponente ausdrucken mussen. 

[0035] Dieser Anforderung tragt der bisher beschriebene Teil des Verifier Frameworks nur bedingt Rechnung. Die 
30 Standardregeln konnten in separaten Verfiern ausgedruckt werden, die Regeln zu den Abweichungen in wieder an- 
deren Verifiern. Der Verifier fur ein Werkzeug bzw. eine Komponente ergibt sich dann durch Zusammenfugen der 
Verfier fur die Standardregeln mit den Verifiem fur die Abweichungen. 

[0036] Oft sind die Unterschiede jedoch so beschaffen, daB ein eigener Verifier nicht gerechtfertigt erscheint und 
stattdessen die Parametrierung von Regeln angemessener ist. In solchen Fallen kommen parametrierbare Verifier 

35 zum Einsatz. Entscheidend dabei ist, daB Parametersatze fur Standardregeln festlegbar sind, die dann im Falle von 
Abweichungen gezielt abgeandert und erweitert werden konnen, ohne dabei die Parameterfestlegungen fur die Stan- 
dardregeln selbst modifizieren oder kopieren zu mussen. Nur so ist gewahrleistet, daB verschiedene Parametersatze 
gleichzeitig aus den Standardsatzen ableitbars\n6, Anderungen an den Standardparametern sich auf alle abgeleiteten 
Satze auswirken, die diese Anderungen nicht bereits speziell umdefinieren und daB die Standardparameter fur weitere 

40 Ableitungen wiederverwendbar bleiben. 

[0037] Dieses Prinzip lehnt sich an die Technik der Vererbung in objektorientierten Software-System en an, wo Klas- 
sen Eigenschaften definieren konnen, die dann von abgeleiteten Klassen uberladen werden konnen. Auch dort sind 
die Ziele die Wiederverwendung der Oberklasse, die automatische Propagierung von Anderungen und Erweiterungen 
der Oberklasse auf bestehende Unterklassen und die Moglichkeit der flexiblen Anpassungen der Unterklassen auf die 

45 geanderten Anforderungen der Spezialisierung, die sie gegenuber der Oberklasse darstellen. 
[0038] Es ergeben sich folgende Merkmale fur die Formulierung von Parametern: 

Parameter werden zu Parametersatzen zusammengefaBt 

50 o Parameter sind innerhalb eines Namensraumes eindeutig identifizierbar 

• Es kann eine Sequenz mehrerer Parametersatze in einem Namensraum vereinigt werden, wobei durch die Rei- 
henfolge eine Uberladungssemantik fur Parameter gleichen Namens im Kontext dieses Namensraumes definiert 
wird. 

55 

Formalisierung der Uberladungssemantik: 

[0039] Sei s := {s 1t s r } eine Sequenz von Parametersatzen mit s, := {(n^p^), (n im(i ^Pj m(j) ) }. Der Satz mit der 
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Ordnungsnummer / besteht also aus einer Menge von m(i) Paaren, deren erstes Element den Namen des Parameters 
im Namensraum und deren zweites Element den Parameterwert angibt. Dann ergibt sich der Wert p des Parameters 
mit dem Namen n im Kontext der Sequenz von Parametersatzen s mit obiger Definintion wie folgt: 




p & falls n i} as n a Vi < k < r : VI < / < m(k) irt^^n 
undefiniert sonst 



Implementierung mit Sequenzen von XML-Dateien 

[0040] Eine Implementierung dieser Semantik kann z.B. so erfolgen, daf3 s abgebildet wird auf eine Sequenz von 
XML-Dateien fd T , d r }. Fur eine Beschreibung des XML-Standards siehe auch Brett McLaughlin, Mike Loukides, 
Java and XML, first edition, O'Reilly & Associates, June 2000, ISBN 05960001 62. Der Namensraum ist bestimmt durch 
die Ausdrucksmoglichkeiten von XML, das im wesentlichen zwischen sogenannten Eiementen und Attributen unter- 
scheidet. Element- und Attributstrukturkonnen vorgegeben werden durch die fur d h ... , d r einheitliche DTD -Document 
Type Definition. Dabei sind Elemente benannt und konnen geschachtelt werden; jedes Element kann eine Menge von 
benannten Attributen aufweisen, die jeweils einen Wert zugewiesen haben konnen. Weiterhin konnen Elemente be- 
liebigen Text in einem Textkorper enthalten, der jedoch hier nicht weiter betrachtet werden soil. 
[0041] Der Name la(3t sich somit eindeutig als ein Elementpfad, also ein Pfad im Gegensatz zu einem einfachen 
Namen aufgrund der potentiellen Schachtelung der Elemente, und abschlieGend den Namen des Attributs des letzten 
Elements in diesem Pfad formulieren. Der Parameterwert ist definiert als der Wert des ausgewahlten Attributes. Er 
kann somit alle Werte annehmen, die ein XML-Attribut annehmen kann. 

[0042] EineXML-Datei d/beschreibt also einen Parametersatz s f . Ein Name n wird realisiert als Pfad, der die Namen 
von geschachtelten Eiementen in der Schachtelungsreihenfolge und am Ende den Namen eines Attributs des innersten 
Elements enthalt. Der Wert des Attributs in der XML-Datei stellt den Wert des Parameters innerhalb des Satzes Sj dar. 
Die Uberladungssemantik kann dann wie oben formalisiert angewendet werden. 

Veranschaulichung, Vorzuge: 

[0043] Bildlich gesprochen ergibt sich durch dieses Verfahren ein "Stapel" von Dateien, die erste Datei d 1 der Liste 
zuunterst, die letzte Gf r zuoberst, wobei gleichnamige Parameter ubereinanderliegen, "undurchsichtig" sind und somit 
"weiter unten" liegende Parameterwerte uberdecken, wohingegen Parameter nach oben "durchscheinen", wenn dar- 
uberliegende Dateien sie nicht uberladen. Siehe dazu die Abbildungsfiguren Fig. 3 bis Fig. 7. 
[0044] In dieser Anordnung reprasentieren die weiter unten liegenden Dateien die Standards, die dann von spezi- 
elleren Parametern fur die Abweichungen angepaBt werden konnen. 

[0045] Mit dieser Implementierung sind Parametersatze z.B. mit einem einfachen Texteditor bearbeitbar, eine Uber- 
setzung als ein separater Schritt zur Nutzbarmachung dieser Informationen, wie dies etwa bei Implementierung eines 
Parametersatzes als Java-Programm anfallen wurde, entfallt 

[0046] Ein parametrierbarer Verifier hat nun neben dem Zugriff auf das Modell des Softwaresystems zusatzlich die 
Menge definierter Parameter zur Verfugung, die sich aus der Zusammenstellung der beschriebenen Sequenz von 
XML-Dateien ergibt und kann deren Werte in die Auswertung der Regeln mit einbeziehen. 

Integration des Verifier Frameworks in Werkzeugketten 

[0047] Die Art und Weise, auf die die Regelprufung in die Werkzeugkette integriert wird, hangt stark von der Be- 
schaffenheit der Kette selbst ab, unter anderem von der Semantik der einzelnen Schritte und der Erweiterbarkeit der 
verwendeten Werkzeuge. Elegant, aber nicht zwingend notwendig, ist naturlich die Integration in ein bestehendes 
Werkzeug hinein, so daB die Regelprufung noch im Werkzeug selbst erfolgen kann und somit die Zeit und der Aufwand 
fur das Hin- und Herschalten zwischen Werkzeug(en) und Regelprufung entfallt. 

[0048] Bieten die Werkzeuge diese Funktionalitat jedoch nicht, so kann dennoch eine Regelprufung durch Ausfuh- 
rung als separates Werkzeug erfolgen, welches dann an einer oder mehreren Stellen in die Werkzeugkette integiert 
wird. 

[0049] Eine weitere Erlauterung der* Erfindung erfolgt anhand von Zeichnungsfiguren. Es zeigen: 

Fig. 1 : Ubersicht Verifier Framework am Beispiel UMUJava/J2EE, 
Fig. 2: Fehlerhaftes Modell, 
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Fig. 3: Veranschaulichung der Uberladungssemantik von Parametersatzen, 
Fig. 4: Standardparameter fur einen parametrierbaren Verifier, 
Fig". 5: Erste Uberladung von Parametern fur einen parametrierbaren Verifier, 
Fig. 6: Zweite Uberlagung von Parameters fur einen parametrierbaren Verifier und 
5 Fig. 7: Ergebnis der angewendeten Uberladungssemantik. 

[0050] Die Diagramme in diesem Abschnitt orientieren sich an der UML-Notation. 

[0051 ] Fig. 1 zeigt den Verifier Manager, seine Beziehung zu den Verif iem und die Struktur der verschiedenen Verifier. 
Der Manager kennt eine beliebige Anzahl von Verifiem. Dabei ist verifier sei bst nur eine Schnittstellenbeschreibung, 

10 wie am Stereotyp «interface» zu erkennen ist, welche die Methodenschnittstelle zum Anwenden des Verifiers auf ein 
Modellelement def iniert. Im Bild sind verschiedene Verifier- Varianten gezeigt, unter anderem ein Verifier, der das Modell 
auf UML-Regeln prufen soil, im Beispiel der UMLVerifier, einer, der es auf Regeln der Sprache Java uberprufen soil 
und ein parametrierbarer Verifier, der die J2EE-spezifischen Regeln prufen soil. Eine Beschreibung des J2EE-Stan- 
dards findet sich beispielsweise in Paul Perrone, Venkata S.R.K.R. Chaganti, Building Java Enterprise Systems with 

15 J2EE, Sams; June 2000, ISBN: 0672317958. Im Bild ist die wichtige Beziehung zwischen den Verifier-lmplementie- 
rungen und der Ver/f/er-Schnittstelle festgehalten: Die konkreten Verifier implementieren die Verifier-Schnittstelle, kon- 
nen somit dem Verifier Manager bekanntgegeben werden, und dieser kann sie polymorph verwenden, urn Modellele- 
mente durch sie prufen zu lassen. 

[0052] Fig. 2 zeigt ein beispielhaftes Modell. An ihm soli die Anwendung einer Menge von Verifiern auf eine Menge 
20 von Modellelementen erlautert werden. Es sei das Verifier-Modell aus Fig. 1 zugrunde gelegt. Auf das in Fig. 2 gezeigte 
Package P soli also die folgende Liste von Verifiern angewendet werden, und zwar auch auf seine enthaltenen Ele- 
mente: < UMLVerifier, JavaVerifier>. Dabei prufe der UMLVerifier die Regel, da(3 ein Interface nie ein Nicht- Interface 
spezialisieren kann. Der Java Verifier prufe die Bedingung, daS kein Classifier mehr als ein Attribut mit demselben 
Namen enthalt. Nun wird zuerst der UMLVerifier auf Package P angewendet. Fur ein Package wendet der Verifier im 
25 Beispiel keine Regel an. AnschlieGend, da auch alle enthaltenen Modellelemente des Packages zu verifizieren sind, 
wird dem Verifier der Reihe nach Modellelement A, dann B und dann C ubergeben. Wahrend bei A und C keine Regel 
des UMLVerifiers verletzt ist, entdeckt er bei S, daG hier ein Interface, namlich B, ein Nicht-lnterface, hier A spezialisiert. 
Damit ist eine Regel verletzt, und es wird eine entsprechende Fehlermeldung mit den Classifiem A und B als beteiligten 
Modellelementen zusammen mit einer beschreibenden Fehlermeldung in die Ergebnisliste eingefugt. 
30 [0053] Der JavaVerifier bekommt auf die gleiche Weise die Classifier A, B und C ubergeben und stellt bei A die 
Verwendung zweier Attribute mit dem gleichen Namen fest. Damit ist eine seiner Regeln verletzt und es wird wieder 
ein Fehlerprotokoll an die Ergebnisliste angehangt. 

[0054] Fig. 3 zeigt die Uberlagerung mehrerer XML-Dateien zur Definition von Parameterwerten, auf die ein para- 
metrierbarer Verifier zugreifen kann. Im Beispiel sind drei Dateien dargestellt: eine zur Beschreibung von Standard- 

35 parametern, eine zur Uberlagerung und Erweiterung der Standardparameter mit speziellen Werten fur ein Produkt X, 
und eine dritte fur zusatzliche Erweiterungen und Umdefinitionen fur ein weiteres Produkt V. Die Grafik soli verdeutli- 
chen, da(3 in dieser Anordnung "weiter oben" liegende Parameterwerte solche, die "weiter unten" liegen, verdecken. 
[0055] Die Abbildungsfiguren Fig. 4 bis Fig. 7 zeigen ein Beispiel fur die Uberlagerung mehrerer Parameterdateien. 
Fig. 4 zeigt die Menge der Standardparameter. Fig. 5 zeigt die Parameter fur Werkzeug / Komponente X und Fig. 6 

40 zeigt diejenigen fur Werkzeug /Komponente Y. Fig. 7 schlieBlich zeigt das Ergebnis der Uberlagerung in der Reihen- 
folge <Standard, X, V>. 

[0056] Das ganze sei nochmals am Beispiel aus Fig. 2 demonstriert. Gegeben seien die folgenden XML-Parameter- 
dateien default.cap, associations.cap und ejbContainerX.cap mit den folgenden auszugsweisen Inhalten: 

45 



50 



55 
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default.cap: 

Associations 

In terf aceFromInter£ace=" supported" 
Interf aceFromClass=" supported" 
ClassPromClass=" supported" 

/> 

associations. cap: 
• • • 

<as sociat ions 

c 0 1 - 0 1= " supported" 

c 0 1 - 0n= " no t_suppor ted" 

cOn-On="not_supported" 

/> 



ejbContainerX.cap: 

<a s sociations 

c0l-0n=" supported" 

/> 

[0057] Der J2EEVerifier prufe die Multiplizitaten der im Modell auftretenden Assoziationen zwischen Classifiem und 
die Stereotypen der Classifier an den Assoziationsenden, also z.B. ob eine Beziehung zwischen Interface und Class 
zulassig ist, oder ob eine Beziehung zwischen zwei Interfaces erlaubt sein soil. Die Menge der erlaubten Multiplizitaten 
werde dabei aus den angegeben XML-Parameterbeschreibungsdateien gewonnen, und zwar im ersten Durchlauf mit 
der Dateiliste <defaultcap, associations. cap>. Bekommt der Verifier das Modellelement ubergeben, welches die As- 
soziation aus Fig. 2 zwischen C und B pruft, dann werden folgende Parameter angefordert: associations:lnterfaceF- 
romClass, da es sich um eine Assoziation von einem Classifier ohne speziellem Stereotyp, also "Class" und einem 
Classifier mit dem Stereotyp M « interfaced handelt; und associations :c01 -On, da das eine Assoziationsende die Multi- 
plizitat "0..1" und das andere "0..n" aufweist. Wahrend der Verifier fur den ersten Parameter "supported* als Wert erhalt, 
was die Beziehung zwischen Class und Interface fur erlaubt erklart, erhalt er fur den zweiten Parameter den Wert 
"not_supportecf\ wie in associations. cap definiert. Es wirdfolglich ein Fehlerreport erzeugt, der die Bund Cals beteiligte 
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Modellelemente nennt und auf die Verletzung der erlaubten Multiplizitaten hinweist. 

[0058] Wird nun zu der Liste der Dateien noch die Datei ejbContainerX.cap hinzugenommen, ergibt sich die Liste 
<default.cap, associations.cap, ejbContainerX.cap>. Wird mit dieser Liste der zuvor beschriebene Durchlauf wieder- 
holt, so meldet der Verifier diesmal keine Regelverletzung, da die Multiplizitatenkombination 0..1/0..n durch die Angabe 
in ejbContainerX.cap als "supported 1 erklart wurde. So kann also ohne einen Eingriff in den Verifier seine Regelmenge 
einfach und unter Einhaltung der zuvor genannten Bedingungen wie etwa Wiederverwendbarkeit der Standardpara- 
meterwerte erweitert /modifiert werden. 



10 Patentanspruche 

1. System zur Verifikation von Software-Anwendungsmodellen in Ketten von Software-En twurfswerkzeugen, uber- 
greifend uber die Aspekte aller beteiligten Warkzeuge und Komponenten entlang einer Kette, wobei 

15 a) die Anwendungsmodelle Instanzen eines Metamodells sind, welches die Struktur von Modellen einer Soft- 

ware-Anwendung sowie Schnittstellen zu diesen Modellen beschreibt, und auf dem alle Werkzeuge der Werk- 
zeugkette aufbauen, 

b) ein Verifier-Framework einschlieBlich einem Verifier-Manager sowie mehrere Verifier existieren, wobei ein 
20 Verifier jeweils als eine Gruppe von formulierten Bedingungen und Regeln fur die Modelle von Software-An- 

wendungen gebildet wird und die Gesamtmenge der jeweils gultigen Regeln und Bedingungen sich ergibt aus 
der Kombination derjenigen Regelgruppen zu den Werkzeugen und Komponenten, die in der verwendeten 
Werkzeugkette arrangiert wurden, und mittels des Verifier-Managers Verifier-Gruppen im Verifier-Framework 
zur Prufung festgelegter Modellelemente zusammengestellt werden, und 

25 

c) das System dafur eingerichtet ist, die Verifizierung von Software-Anwendungsmodellen bezuglich Vertrag- 
lichkeitmit den formulierten Bedingungen und Regeln mittels eines Uberprufungslaufs unter Verwendung des 
Metamodells durch Ausfuhrung der anzuwendenden Verifier auf den zuvor festgelegten Modellelementen vor- 
zunehmen, wobei sich als Ergebnis die festgestellten Bedingungs- oder Regelverletzungen ergeben. 

30 

2. System nach Anspruch 1 , dadurch gekennzeichnet, daB das Metamodell auf dem UML(Unified Modeling Lan- 
guage)-Standard basiert. 

3. System nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB es dafur eingerichtet ist, pa- 
35 rametrierbare Verifier zu bilden und zu verwenden, die es ermoglichen, in der Regelformulierung neben dem An- 

wendungsmodell auch auf die Werte dieser Parameter zuzugreifen und somit die Regeln durch Parametersatze 
anzupassen, ohne die Regeln selbst andern zu mussen. 

4. System nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB der Verifier-Manager dafur 
*o eingerichtet ist,einzelne Verifier dynamisch zu einem Uberprufungslauf hinzuzunehmen oder abzuschalten. 

5. System nach Anspruch 4, dadurch gekennzeichnet, daB der Verifier-Manager dafur eingerichtet ist, die dyna- 
mische Zu- oder Abschaltung von Verifiern programmatisch durchzuf uhren, oder es zu ermoglichen, daB sie durch 
ein Anwenderprogramm erfolgt, das sich der Funktionalitat des Verifier-Frameworks bedient, oder durch eine ei- 

45 gene interaktive Benutzungsschnittstelle des Verifier- Frameworks. 

6. System nach einem der Anspruche 3, 4 oder 5, dadurch gekennzeichnet, daB es dafur eingerichtet ist, Parame- 
tersatze fur parametrierbare Verifier aus Sequenzen von Parametersatzen zusammenzusetzen, bei denen entlang 
der Sequenz Parameterwerte uberladen werden. 

50 

7. System nach Anspruch 6, gekennzeichnet dadurch, daB die Parametersatze fur paramerierbare Verifier in Text- 
dateien im ASCII-Format abgelegt sind. 

8. System nach Anspruch 7, dadurch gekennzeichnet, daB als innere Struktur der Textdateien das XML-Format 
55 verwendet ist. 

9. System nach einem der vorstehenden Anspruche, dadurch gekennzeichnet, daB das System in der Program- 
miersprache Java erstellt ist. 
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Claims 

1. System for the verification of software application models in chains of software design tools with the following 
specifications: 

a) The application models are instances of a metamodel which describes the structure of a software application 
as well as the interfaces to these models. All tools along the tool chain are based on this metamodel. 

b) The system comprises a Verifier Framework including a Verifier Manager as well as several verifiers. Each 
verifier constitutes a group of formulated conditions and rules for one of the models of the software application. 
The Verifier Manager allows for the combination of verifier groups within the Verifier Framework for the veri- 
fication of specified model elements. 

c) The system is designed for the verification of software models in terms of their compliance with the formu- 
lated conditions and rules by means of a verification run using the metamodel. The result of the verification 
run is a list of the violations of conditions and rules detected. 

2. System according to claim 1 which is characterized by the fact that the metamodel is based on the UML(Unified 
Modeling Language) standard. 

3. System according to one of the above claims which is characterized by the fact that it allows for the composition 
and usage of parameterizable verifiers. These parameterizable verifiers enable access to the values of these 
parameters in addition to the application model so that the rules can be modified by means of parameter sets 
without the rules themselves having to be modified. 

4. System according to one of the above claims which is characterized by the fact that it provides a Verifier Manager 
which allows for the dynamic activation or deactivation of individual verifiers for specific verification runs. 

5. System according to claims 4 which is characterized by the fact that the Verifier Manager is designed in such a 
way as to allow for the programmatic dynamic activation or deactivation of verifiers, or to enable an application 
program to do so by using the functionality of the Verifier Framework, or by using the separate interactive user 
interface of the Verifier Framework. 

6. System according to one of the above claims 3, 4 or 5 which is characterized by the fact that it is designed in 
such a way as to allow for the composition of parameter sets for parameterizable verifiers on the basis of sequences 
of parameters sets which enable the redefinition of parameter values within the sequence by means of overruling 
semantics. 

7. System according to claim 6 which is characterized by the fact that the parameter sets for parameterizable verifiers 
are stored as text files in ASCII format. 

8. System according to claim 7 which is characterized by the fact that the XML format is used for the inner structure 
of the text files. 

9. System according to one of the above claims which is characterized by the fact that the system is created in the 
programming language Java. 



Revendications 

i . Systeme de verification de modeles duplications au sein d'une chaine d'outils de planification et d'implementation 
avec les specifications suivantes : 

a. Les modeles de I'application sont des instances d'un metamodele. Le metamodele decrit la structure de 
I'application ainsi que les interfaces pour les modeles. Tous les outils appartenant a la chaine sont bases sur 
ce metamodele. 

b. Le systeme comprend un ensemble d'outils de verificateurs (Verifier Framework") incluant un gestionnaire 
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de verificateurs ("Verifier Manager") ainsi que plusieurs verificateurs. Chaque verificateur represente un en- 
semble de conditions et de regies bien definies pour les modeles des applications. Le gestionnaire de verifi- 
cateurs permet de combiner un ensemble de verificateurs appartenant au "Verifier Framework" et permet ainsi 
la verification de certains elements specifies d'un modele. 

c. Le systeme est congu pour permettre la verification de la conformite des modeles des applications avec les 
conditions et les regies specifiers. Le metamodele sert de base au deroulement de la verification dont le 
resultat represente une liste des violations detectees des conditions et regies specifies. 

Systeme comme decrit a la revendication 1 , caracterise par le fait que le metamodele est base sur le standard 
UML (Unified Modeling Language). 

Systeme conforme a Tune des revendications precedentes, caracterise par le fait qu'il permet la composition et 
I'usage de verificateurs parametrables. Ces verificateurs parametrables permettent lors de la definition des regies 
d'acceder non seulement au modele d'application mais egalement aux valeurs de ces parametres et par conse- 
quent d'adapter les regies par des ensembles de parametres sans qu'il soit necessaire de modifier les regies elles- 
memes. 

Systeme conforme a I'une des revendications precedentes, caracterise par le fait que le gestionnaire de verifi- 
cateurs permet I'activation et la desactivation dynamique de certains verificateurs pour un certain deroulement de 
verification. 

Systeme conforme a la revendication 4, caracterise par le fait que le gestionnaire de verificateurs est concu de 
maniere a permettre I'activation et la desactivation dynamique des verificateurs, ceci d'une maniere programma- 
tique ou bien a I'aide d'un programme d'application qui se sert des fonctionnalites du Verifier Framework ou bien 
en faisant appel a I'interface interactive du Verifier Framework. 

Systeme conforme a Tune des revendications 3, 4 ou 5, caracterise par le fait qu'il est congu de maniere a 
permettre la composition des ensembles de parametres pour verificateurs parametrables sur la base de sequences 
d'ensembles de parametres au cours desquelles d'autres valeurs peuvent etre prises au sein de la sequence. 

Systeme conforme a la revendication 6, caracterise par le fait que les ensembles de parametres des verificateurs 
parametrables sont enregistres sous forme de fichiers de texte ASCII. 

Systeme conforme a la revendication 7, caracterise par le fait que ie format XML est utilise pour la structure 
interne des fichiers de texte. 

Systeme conforme a I'une des revendications precedentes, caracterise par le fait que le systeme est ecrit a I'aide 
du langage de programmation Java. 
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Fig. 2: Fehlerhaftes Modell 
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Fig. 3: Veranschaulichung der Qberladungssemantik von Parametersatzen 
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Fig. 4: Standardparameter fur einen parametrierbaren Verifier 
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Fig. 5: Erste Uberladung von Parameters* fur einen parametrierbaren Verifier 
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/////// Attribut uberschrieben von X 
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Fig. 6: Zweite Oberladung von Parameters fur einen parametrierbaren Verifier 
Parameter der Liste <Standard, X, Y> 
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Fig. 7: Ergebnis der angewendeten Uberladungssemantik 
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